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Abstract —Proving program termination is key to guaranteeing 
absence of undesirable behaviour, such as hanging programs and 
even security vulnerabilities such as denial-of-service attacks. To 
make termination checks scale to large systems, interprocedural 
termination analysis seems essential, which is a largely unex¬ 
plored area of research in termination analysis, where most effort 
has focussed on difficult single-procedure problems. We present 
a modular termination analysis for C programs using template- 
based interprocedural summarisation. Our analysis combines a 
context-sensitive, over-approximating forward analysis with the 
inference of under-approximating preconditions for termination. 
Bit-precise termination arguments are synthesised over lexico¬ 
graphic linear ranking function templates. Our experimental 
results show that our tool 2LS outperforms state-of-the-art alter¬ 
natives, and demonstrate the clear advantage of interprocedural 
reasoning over monolithic analysis in terms of efficiency, while 
retaining comparable precision. 

I. Introduction 

Termination bugs can compromise safety-critical software 
systems by making them irresponsive, e.g., termination bugs 
can be exploited in denial-of-service attacks JT]. Termination 
guarantees are therefore instrumental for software reliability. 
Termination provers, static analysis tools that aim to construct 
a termination proof for a given input program, have made 
tremendous progress. They enable automatic proofs for com¬ 
plex loops that may require linear lexicographic (e.g. El, B) 
or non-linear termination arguments (e.g. |j4l) in a completely 
automatic way. However, there remain major practical chal¬ 
lenges in analysing real-world code. 

First of all, as observed by a, most approaches in the 
literature are specialised to linear arithmetic over unbounded 
mathematical integers. Although, unbounded arithmetic may 
reflect the intuitively-expected program behaviour, the pro¬ 
gram actually executes over bounded machine integers. The 
semantics of C allows unsigned integers to wrap around when 
they over/underflow. Hence, arithmetic on fc-bit-wide unsigned 
integers must be performed modulo-2^. According to the C 
standards, over/underflows of signed integers are undefined 
behaviour, but practically also wrap around on most architec¬ 
tures. Thus, accurate termination analysis requires a bit-precise 
analysis of program semantics. Tools must be configurable 
with architectural specifications such as the width of data 
types and endianness. The following examples illustrate that 
termination behaviour on machine integers can be completely 
different than on mathematical integers. For example, the 
following code: 

void foo 1 (unsigned n) { for(unsigned x = 0; x<=n; x-F-b); } 


does terminate with mathematical integers, but does not ter¬ 
minate with machine integers if n equals the largest unsigned 
integer. On the other hand, the following code: 

void foo2 (unsigned x) { while(x> = 10) x-f-f; } 

does not terminate with mathematical integers, but terminates 
with machine integers because unsigned machine integers 
wrap around. 

A second challenge is to make termination analysis scale to 
larger programs. The yearly Software Verification Competition 
(SV-COMP) B includes a division in termination analysis, 
which reflects a representative picture of the state-of-the-art. 
The SV-COMP’15 termination benchmarks contain challeng¬ 
ing termination problems on smaller programs with at most 
453 instructions (average 53), contained at most 7 functions 
(average 3), and 4 loops (average 1). 

In this paper, we present a technique that we have suc¬ 
cessfully run on programs that are one magnitude larger, 
containing up to 5000 instructions. Larger instances require 
different algorithmic techniques to scale, e.g., modular inter¬ 
procedural analysis rather than monolithic analysis. This poses 
several conceptual and practical challenges that do not arise in 
monolithic termination analysers. For example, when proving 
termination of a program, a possible approach is to try to 
prove that all procedures in the program terminate universally, 
i.e., in any possible calling context. However, this criterion is 
too optimistic, as termination of individual procedures often 
depends on the calling context, i.e., procedures terminate 
conditionally only in specific calling contexts. 

Hence, an interprocedural analysis strategy is to verify uni¬ 
versal program termination in a top-down manner by proving 
termination of each procedure relative to its calling contexts, 
and propagating upwards which calling contexts guarantee 
termination of the procedure. It is too difficult to determine 
these contexts precisely; analysers thus compute preconditions 
for termination. A sufficient precondition identifies those pre¬ 
states in which the procedure will definitely terminate, and is 
thus suitable for proving termination. By contrast, a necessary 
precondition identifies the pre-states in which the procedure 
may terminate. Its negation are those states in which the 
procedure will not terminate, which is useful for proving 
nontermination. 

In this paper we focus on the computation of sufficient pre¬ 
conditions. Preconditions enable information reuse, and thus 
scalability, as it is frequently possible to avoid repeated anal¬ 
ysis of parts of the code base, e.g. libraries whose procedures 


are called multiple times or did not undergo modifications 
between successive analysis runs. 

Contributions: 

1) We propose an algorithm for interprocedural termination 
analysis. The approach is based on a template-based static 
analysis using SAT solving. It combines context-sensitive, 
summary-based interprocedural analysis with the infer¬ 
ence of preconditions for termination based on template 
abstractions. We focus on non-recursive programs, which 
cover a large portion of software written, especially in 
domains such as embedded systems. 

2) We provide an implementation of the approach in 2LS, a 
static analysis tool for C programs. Our instantiation of 
the algorithm uses template polyhedra and lexicographic, 
linear ranking functions templates. The analysis is bit- 
precise and purely relies on SAT-solving techniques. 

3) We report the results of an experimental evaluation on 
597 procedural SV-COMP benchmarks with in total 1.6 
million lines of code that demonstrates the scalability and 
applicability of the approach to programs with thousands 
of lines of code. 

II. Preliminaries 

In this section, we introduce basic notions of interprocedural 
and termination analysis. 

Program model and notation. We assume that programs 
are given in terms of acyclicQ call graphs, where individual 
procedures / are given in terms of symbolic input/output 
transition systems. Formally, the input/output transition system 
of a procedure / is a triple {Initf, Transf, Outf), where 
Transf(x,x') is the transition relation; the input relation 
Initf{x™^x) defines the initial states of the transition sys¬ 
tem and relates it to the inputs a;®"; the output relation 
Outf{x,x°‘^*) connects the transition system to the outputs 
xout j-jjg procedure. Inputs are procedure parameters, global 
variables, and memory objects that are read by /. Outputs 
are return values, and potential side effects such as global 
variables and memory objects written by /. Internal states x 
are commonly the values of variables at the loop heads in /. 

These relations are given as first-order logic formulae 
resulting from the logical encoding of the program semantics. 
Fig. |2] shows the encoding of the two procedures in Fig. [T] into 
such formulaell The inputs a;®" of / are (z) and the outputs 
xOut consist of the return value denoted (r/). The transition 
relation of h encodes the loop over the internal state variables 
{x,yY'. We may need to introduce Boolean variables g to 
model the control flow, as shown in /. Multiple and nested 
loops can be similarly encoded in Trans. 

Note that we view these formulae as predicates, e.g. 
Trans{x,x'), with given parameters x^x', and mean the 
substitution Trans[a/x,b/x'] when we write Trans{a,b). 

* We consider non-recursive programs with multiple procedures. 

^c?a:b is the conditional operator, which returns a if c evaluates to true, 
and b otherwise. 


1 unsigned f(unsigned z) { i unsigned h(unsigned y) { 

2 unsigned w= 0 ; 2 unsigned x; 

3 if(z> 0 ) w=h(z); 3 for(x = 0 ; x< 10 ; x+=y); 

4 return w; 4 return x; 

5 } 5 } 

Eig. 1. Example. 

Initf{{z), (w, z,g)'^) = (tuo=0 A z'=z A g) 

Trans f{{w, z, g)'^, (w', z', g')'^) = {g /\ ho{{z), (tui))A 

w={z>0?wi:wo) A -ig') 

Outf{{w,z,g)'^ ,{rf)) ={rf=w) 

Inith(iy), {x,y'Y) = (x=0 A y'=y) 

Transh{(x, (x'= {x'=x-\-y A x<10 A y=y') 

Outu({x, g)^, {ru)) = (rh=x A -.(a:<10)) 

Fig. 2. Encoding of Example [T] 

Moreover, we write x and x with the understanding that the 
former is a vector, whereas the latter is a scalar. 

Each call to a procedure h at call site f in a procedure / 
is modeled by a placeholder predicate /ii(a:^’-®”i, a:P-°®®*i) 
occurring in the formula Trans / for /. The placeholder pred¬ 
icate ranges over intermediate variables representing its actual 
input and output parameters x^-^i and respectively. 

Placeholder predicates evaluate to true, which corresponds 
to havocking procedure calls. In procedure / in Fig. |2] the 
placeholder for the procedure call to h is ho{{z), (wi)) with 
the actual input and output parameters z and wi, respectively. 

A full description of the program encoding is given in 
Appendix 

Basic concepts. Moving on to interprocedural analysis, we 
introduce formal notation for the basic concepts below: 

Definition 1 (Invariants, Summaries, Calling Contexts). For a 
procedure given by {Init, Trans, Out) we define: 

« An invariant is a predicate Inv such that: 

\/x^^,x,x' : Init{x'^'^,x) => Inv{x) 

A Inv(x) A Trans{x,x') Inv{x') 

• Given an invariant Inv, a summary is a predicate Sum 
such that: 

\lx™,x, x', a;®”®* : Init{x'''^, x) A Inv{x') A Out{x', at®”®* 
^ Sum{x^'^,x°^*) 

« Given an invariant Inv, the calling context for a pro¬ 
cedure call h at call site i in the given procedure is a 
predicate CallCtxhi such that 

W™ . ^p_out . . 

V nJL/ ^ nJU ^ tju 'I ^ uU 2 • 

Inv{x) A Trans{x,x') => CallCtxhi{xP-^i,xP-°'^*i) 

These concepts have the following roles: Invariants abstract 
the behaviour of loops. Summaries abstract the behaviour of 
called procedures; they are used to strengthen the placeholder 
predicates. Calling contexts abstract the caller’s behaviour 
w.r.t. the procedure being called. When analysing the callee, 
the calling contexts are used to constrain its inputs and outputs. 

In Sec.|III]we will illustrate these notions on the program in 
Fig.m 

Since we want to reason about termination, we need the 
notions of ranking functions and preconditions for termination. 



Definition 2 (Ranking function). A ranking function for a 
procedure {Init, Trans, Out) with invariant Inv is a function 
r from the set of program states to a well-founded domain 
such that Mx^x' : Inv{x) A Trans{x,x') => r{x) > r{x'). 

We denote by RR{x, x') a set of constraints that guarantee 
that r is a ranking function. The existence of a ranking function 
for a procedure guarantees its universal termination. 

The weakest termination precondition for a procedure de¬ 
scribes the inputs for which it terminates. If it is true, the 
procedure terminates universally; if it is false, then it does 
not terminate for any input. Since the weakest precondition 
is intractable to compute or even uncomputable, we under¬ 
approximate the precondition. A sufficient precondition for 
termination guarantees that the program terminates for all a;™ 
that satisfy it. 

Definition 3 (Precondition for termination). Given a proce¬ 
dure [Init, Trans, Out), a sufficient precondition for termina¬ 
tion is a predicate Precond such that 

3RR, Inv : Va;*", x, x' : 

Precond{x™) A Init{x™, x) Inv{x) 

A Inv(x) A Trans{x, x') => Inv{x') A RR{x, x') 

Note that false is always a trivial model for Precond, but 
not a very useful one. 

III. Overview oe the Approach 

In this section, we introduce the architecture of our interpro¬ 
cedural termination analysis. Our analysis combines, in a non¬ 
trivial synergistic way, the inference of invariants, summaries, 
calling contexts, termination arguments, and preconditions, 
which have a concise characterisation in second-order logic 
(see Definitions [T] andO. At the lowest level our approach 
relies on a solver backend for second-order problems, which 
is described in Sec. lYl 

To see how the different analysis components fit together, 
we now go through the pseudo-code of our termination 
analyser (Algorithm [TJ. Function analyze is given the entry 
procedure f entry of the program as argument and proceeds in 
two analysis phases. 

Phase one is an over-approximate forward analysis, given 
in subroutine analyzeForward, which recursively descends 
into the call graph from the entry point fentry Subroutine 
analyzeForward infers for each procedure call in / an over¬ 
approximating calling context CallCtx°, using procedure sum¬ 
maries and other previously-computed information. Before 
analyzing a callee, the analysis checks if the callee has already 
been analysed and, whether the stored summary can be re¬ 
used, i.e., if it is compatible with the new calling context 
CallCtx°. Finally, once summaries for all callees are available, 
the analysis infers loop invariants and a summary for / itself, 
which are stored for later re-use by means of a join operator. 

The second phase is an under-approximate backward anal¬ 
ysis, subroutine analyzeBackward , which infers termination 
preconditions. Again, we recursively descend into the call 
graph. Analogous to the forward analysis, we infer for each 


Algorithm 1: analyze 


1 global Sums°, Invs°, Preconds'^; 

2 function analyzeForward{f, CallCtXf) 

3 

foreach procedure call h in f do 

4 


CallCtXf,^ = compCallCtx°{f, CallCtXf, h)'. 

5 


if needToReAnalyze°[h, CallCtx'^) then 

6 


analyzeForutard(h, CallCtxf,)', 

7 

join° {{Sums°[f], Invs°[f]), compInvSum°{f, CallCtx°f)) 

8 function analyzeBackward{f, CallCtxf) 

9 

termConds = CallCtxf, 

10 

foreach procedure call h in f do 

11 


CallCtxl = compCallCtx'^if, CallCtx'j,h)'. 

12 


if needToReAnalyze'^(h, CallCtx'f) then 

13 


analyzeBackwardih, CallCtx^)', 

14 


termConds t— termConds A Preconds"[h]'. 


join^ [Preconds'^ [/], 



compPrecondTerm{f, Invs°[f], termConds)', 

16 fnnction analyze{fentry) 

17 

analyzeForward{fentry, true)'. 

18 

analyzeBackward{fentry, true)'. 

19 

return Preconds “ [f entry ]; 


procedure call in / an under-approximating calling context 
CallCtx'^ (using under-approximate summaries, as described 
in Sec. llVb . and recurses only if necessary (Line [T2|. Fi¬ 
nally, we compute the under-approximating precondition for 
termination (Line [TST l. This precondition is inferred w.r.t. the 
termination conditions that have been collected: the backward 
calling context (Line |9]), the preconditions for termination of 
the callees (Line fT4l) . and the termination arguments for / 
itself (see Sec. lYl). Note that superscripts o and u in predicate 
symbols indicate over- and underapproximation, respectively. 

Challenges. Our algorithm uses over- and under¬ 
approximation in a novel, systematic way. In particular, 
we address the challenging problem of finding meaningful 
preconditions: 

• The precondition Definition [3 admits the trivial solution 
false for Precond. How do we find a good candidate? 
To this end, we “bootstrap” the process with a candidate 
precondition: a single value of a;™, for which we compute 
a termination argument. The key observation is that the 
resulting termination argument is typically more general, 
i.e., it shows termination for many further entry states. 
The more general precondition is then computed by 
precondition inference w.r.t. the termination argument. 

• A second challenge is to compute under-approximations. 
Obviously, the predicates in the definitions in Sec. Ullcan 
be over-approximated by using abstract domains such as 
intervals. However, there are only few methods for under¬ 
approximating analysis. In this work, we use a method 
similar to 13 to obtain under-approximating precondi¬ 
tions w.r.t. property p: we infer an over-approximating 
precondition w.r.t. -ip and negate the result. In our case, 
p is the termination condition termConds. 










Example. We illustrate the algorithm on the simple example 
given as Fig. [T] with the encoding in Fig.|2] f calls a procedure 
h. Procedure h terminates if and only if its argument y is 
non-zero, i.e., procedure f only terminates conditionally. The 
call of h is guarded by the condition z>0, which guarantees 
universal termination of procedure f . 

Let us assume that unsigned integers are 32 bits wide, and 
we use an interval abstract domain for invariant, summary 
and precondition inference, but the abstract domain with the 
elements {true, false} for computing calling contexts, i.e., we 
can prove that calls are unreachable. We use M := 2^^— 1. 

Our algorithm proceeds as follows. The first phase is 
analyzeForward, which starts from the entry procedure f. 
By descending into the call graph, we must compute an over¬ 
approximating calling context CallCtx°i, for procedure h for 
which no calling context has been computed before. This 
calling context is true. Hence, we recursively analyse h. Given 
that h does not contain any procedure calls, we compute the 
over-approximating summary Sumf = {0<y<MA0<rh<M) 
and invariant Inv^ = {0<x<M A Q<y<M). Now, this 
information can be used in order to compute Sum!} = 
{0<z<M A 0<rf<M) and invariant Inv} = true for the 
entry procedure f . 

The backwards analysis starts again from the entry proce¬ 
dure f. It computes an under-approximating calling context 
CallCtx}, for procedure h, which is true, before descending 
into the call graph. It then computes an under-approximating 
precondition for termination Precondf^ = {l<y<M) or, more 
precisely, an under-approximating summary whose projection 
onto the input variables of h is the precondition Precond},. 
By applying this summary at the call site of h in f, we can 
now compute the precondition for termination Precond} = 
{0<z<M) of f , which proves universal termination of f . 

We illustrate the effect of the choice of the abstract domain 
on the analysis of the example program. Assume we replace 
the {true,false} domain by the interval domain. In this 
case, analyzeForward computes CallCtxf, = {l<z<M A 
0<wi<M). The calling context is computed over the actual 
parameters z and wi . It is renamed to the formal parameters y 
and rh (the return value) when CallCtxf is used for constrain¬ 
ing the pre/postconditions in the analysis of h. Subsequently, 
analyzesackward computes the precondition for termination 
of h using the union of all calling contexts in the program. 
Since h terminates unconditionally in these calling contexts, 
we trivially obtain Precond'f = (l<t/<M), which in turn 
proves universal termination of f . 

IV. Interprocedural Termination Analysis 

We can view Alg. [T] as solving a series of formulae 
in second-order predicate logic with existentially quantified 
predicates, for which we are seeking satisfiability witnesses^ 
In this section, we state the constraints we solve, including all 
the side constraints arising from the interprocedural analysis. 

^ To be precise, we are not only looking for witness predicates but (good 
approximations of) weakest or strongest predicates. Finding such biased 
witnesses is a feature of our synthesis algorithms. 


Algorithm 2: analyze for universal termination 


1 global Sums°, Invs°, termStatus; 

2 function analyzeForward{f, CallCtx}) 

3 foreach procedure call h in f do 

4 CallCtx'^ = compCallCtx°{f, CallCtXf,h); 

5 if needToReAnalyze°{h, CallCtxl^) then 

6 analyzeForward{h, CallCtx'^)’, 

7 join°{{Sums°[f], Invs°[f]), compInvSum°{f, CallCtx})) 


8 

9 

10 

11 

12 

13 


function analyzeBackward'{f) 

termStatus[f] = compTermArg{f)', 
foreach procedure call h in f do 

if needToReAnalyze^ {h, CallCtxf) then 
analyzeBackward {h)', 
join( termStatus [/], termStatus [ft]); 


14 

15 

16 
17 


fnnction analyze{fentry) 

analyzeForward{fentry, true)', 
analyzeBackward' {f entry)', 
return termStatus[f entry]'. 


Note that this is not a formalisation exercise, but these are 
precisely the formulae solved by our synthesis backend, which 
is described in Section |V] 

A. Universal Termination 

For didactical purposes, we start with a simplification of 
Algorithm [T] that is able to show universal termination (see 
Algorithm |2|i. This variant reduces the backward analysis to 
a call to compTermArg and propagating back the qualitative 
result obtained; terminating, potentially non-terminating, or 
non-terminating. 

This section states the constraints that are solved to compute 
the outcome of the functions underlined in Algorithm |2] and 
establish its soundness: 

• compCallCtx° 

• compInvSum° (Def. B 

• compTermArg (Lemma O 


Definition 4 (compCallCtx°). A forward calling context 
CallCtx},. for hi in procedure f in calling context CallCtx} 
is a satisfiability witness of the following formula: 

3CallCtxf^, Inv} : Vtc™, x, x', : 

CallCtx}{x'''^ ,x°''^^) A Sums} A Assumptionsf{x) 
[lnitf{x™,x) Inv}{x)) 

A (^Inv}{x) A Trans fix, x') 

Inv}{x') A {ghi ^ CallCtxf.{x^-'''i,x^-°'^* *'i)} 

with Sums} = Aealls h, m / 9h, 

Sums°[h]{xP-^^j,xP-°'^*j) 

where gy. is the guard condition of procedure call hj in 
/ capturing the branch conditions from conditionals. For 
example, gy^ of the procedure call to h in f in Fig.[T|is z > 0. 
Sums°[h] is the currently available summary for h (cf. global 
variables in Alg. [T]i. Assumptions correspond to assume {) 
statements in the code. 














Lemma 1. CallCtx'^. is over-approximating. 

Proof sketch. CallCtx°f when / is the entry-point proce¬ 
dure is true', also, the summaries Sumf^. are initially as¬ 
sumed to be true, i.e. over-approximating. Hence, given that 
CallGtx°f and Sums°f are over-approximating, CallCtx'},^. is 
over-approximating by the soundness of the synthesis (see 
Thm.EJin Sec.®. □ 


Example. Let us consider procedure f in Fig. [T] f is the 
entry procedure, hence we have CallCtx°f{{z),{rf)) = true 
(= (0<z<M A 0<r/<M) with M := 2^^ —1 when using 
the interval abstract domain for 32 bit integers). Then, we 
instantiate Def.|4] (for procedure f) to compute CallCtx’}^^. We 
assume that we have not yet computed a summary for h, thus, 
Surrih is true. Remember that the placeholder hQ{{z), (wi)) 
evaluates to true. Notably, there are no assumptions in the 
code, meaning that Assumptionsf{z) = true. 

3CallCtx°i^^, Iriv°j : Vz, wi,w, w', z', g, g', Vf : 

0<z<M A 0<rf<M A (z>0 true) A true 
[w=0 A z'=z A g Inv°f{(w, z, g)'^)) 

A \lnv°f{{w,z,g)'^)h 

g A hQ{{z), (wi)) A w'={z>t)lwi'.w) A z'=z A -^g' 

=> Inv°f \{w', z', g')'^) A (z>0 ^ CallCtx‘^.{{z), (wi))) 
A solution is Inv°j: = true, and CaUCtx'^^{{z), (wi)) = 
{l<z<M A0<wi<M). 

Definition 5 { compInvSum°). A forward summary Sumj and 
invariants Inv°j: for procedure / in calling context CallCtx°f 
are satisfiability witnesses of the following formula: 

3Sum%Inv°f : 

CallCtx°f{x'^'^,x°'^*) A Sums°f A Assumptionsf{x) 
(^Initf{x^'^, x) A Inv°f{x") A Outf{x", 

=> Inv°f{x) A Sum°f{x'^^, 

A {^Inv°f{x) A Transf{x,x') => Inv°j(x')) 

Lemma 2. Sum°j and Inv°f are over-approximating. 

Proof sketch. By Lemma [1] CallCtx°^ is over-approximating. 
Also, the summaries Sums°j: are initially assumed to be 
true, i.e. over-approximating. Hence, given that CallCtx°f and 
Sums°j are over-approximating, Sum°f and Inv°j are over¬ 
approximating by the soundness of the synthesis (Thm.O. □ 


Example. Let us consider procedure h in Fig. [T] We have 
computed CallCtx^^{{y),{rh)) = (l<y<M A 0<rh<M) 
(with actual parameters renamed to formal ones). Then, we 
need obtain witnesses and Sum'^^ to the satifiability of 

the instantiation of Def. |5] (for procedure h) as given below. 

^ 

\<y<M A 0<rh<M A true 

((a:=0 A y'=y) A InvUix",y")'^) A {rh=x" A -'(x"<10) 
^ Invliix, A Sumldy), {ru))) 

A{lnvl{{x, j/)^) A {x'={x-\-y A x<10) A y=y') 
Invl{{x',yY)) 

A solution is = {0<x<MAl<y<M) and Sum'^^ = 

{^‘£y‘£AI A 10<r/j<M), for instance. 


Remark 1. Since Def. ^and Def. |5]are interdependent, we can 
compute them iteratively until a fixed point is reached in order 
to improve the precision of calling contexts, invariants and 
summaries. However, for efficiency reasons, we perform only 
the first iteration of this (greatest) fixed point computation. 

Lemma 3 (comp TermArg). A procedure f with forward 
invariants In,v°f terminates if there is a termination argument 

RRf-' 

3RRf : 'ix, x' : 

Inv°f(x) A Transf{x,x')A 

Sums°f A Assumptionsf(x) A Assertionsf(x) 

==A RRf(x, x') 

Assertions in this formula correspond to to assert {) 
statements in the code. They can be assumed to hold be¬ 
cause assertion-violating traces terminate. Over-approximating 
forward information may lead to inclusion of spurious non¬ 
terminating traces. For that reason, we might not find a 
termination argument although the procedure is terminating. 
As we essentially under-approximate the set of terminating 
procedures, we will not give false positives. Regarding the 
solving algorithm for this formula, we refer to Sec. lYl 
Example. Let us consider function h in Fig. [T] Assume we 
have the invariant 0<x<MAl<y<M. Thus, we have to solve 

3RRh : 0<x<M A l<y<M A x'=x-\-y A x<10 A y'=yA 
true A true => RRh{{x, y), (x', y')) 

When using a linear ranking function template ci • x -f C 2 • y, 
we obtain as solution, for example, RRh = (— x> — x'). 

If there is no trace from procedure entry to exit, then we can 
prove non-termination, even when using over-approximations: 

Lemma 4 (line |7] of analyze). A procedure f in forward 
calling context CallCtx°p and forward invariants Inv^j never 
terminates if its summary Sum°j is false. 

Termination information is then propagated in the (acyclic) 
call graph (join in line [13] in Algorithmic: 

Proposition 1. A procedure is declared 

(1) non-terminating if it is non-terminating by Lemma |C 

(2) terminating if 

(a) all its procedure calls hi that are potentially reach¬ 
able (i.e. with CallCtx‘1^. false) are declared termi¬ 
nating, and 

(b) f itself is terminating according to Lemma^ 

(3) potentially non-terminating, otherwise. 

Our implementation is more efficient than Algorithm [2] 
because it avoids computing a termination argument for / if 
one of its callees is potentially non-terminating. 

Theorem 1. If the entry procedure of a program is declared 
terminating, then the program terminates universally. If the 
entry procedure of a program is declared non-terminating, 
then the program never terminates. 

Proof sketch. By induction over the acyclic call graph using 

Prop, m □ 


Algorithm 3: compPrecondTerm 


Input: procedure / with invariant Inv, additional termination 
conditions termConds 
Output: precondition Precond 

1 [Precond,p) [false, true)’, 

2 let yj = Init[x''", x) A Inv[x)’, 

3 while true do 

4 t/) •<—p A-'Precond(a:®'‘) A 

5 solve if for a:®", x, a;'; 

6 if UNSAT then return Precond else 

7 let X™ be a model of ip’, 

8 let Inv' = compInv[f,x^"=x‘'^)’-> 

9 let TZIZ = compTermArg[f, Inv')’, 

to if IZIZ = true then p p A [x'’" ^ x*") else 

11 let Q = termConds A IZIZ’, 

12 let Precond' = -icompNecPrecond[f, -<9)’, 

13 Precond t— Precond V Precond'’, 


B. Preconditions for Termination 

Before introducing conditional termination, we have to talk 
about preconditions for termination. 

If a procedure terminates conditionally like procedure h in 
Fig. [T] compTermArg (Lemma O will not be able to find 
a satisfying predicate RR. However, we would like to know 
under which preconditions, i.e. values of y in above example, 
the procedure terminates. 

We can state this problem as defined in Def. [3 In Algo- 
rithm[3we search for Precond, Inv, and RR in an interleaved 
manner. Note that false is a trivial solution for Precond’, we 
thus have to aim at finding a good under-approximation of the 
maximal solution (weakest precondition) for Precond. 

We bootstrap the process by assuming Precond = false 
and search for values of a;®" (Line |5]). If such a value x™ 
exists, we can compute an invariant under the precondition 
candidate x™ = x*” (Line [3 and use Lemma [3 to search for 
the corresponding termination argument (Line|9l). 

If we fail to find a termination argument (IZIZ = true), 
we block the precondition candidate (Line fTOl i and restart 
the bootstrapping process. Otherwise, the algorithm returns a 
termination argument IZIZ that is valid for the concrete value 
X*" of at®". Now we need to find a sufficiently weak Precond 
for which IZIZ guarantees termination. To this end, we com¬ 
pute an over-approximating precondition for those inputs for 
which we cannot guarantee termination (-i0 in Line[T3 which 
includes additional termination conditions coming from the 
backward calling context and preconditions of procedure calls, 
see Sec. lIV-Cl l. The negation of this precondition is an under¬ 
approximation of those inputs for which / terminates. Finally, 
we add this negated precondition to our Precond (Line fTJt 
before we start over the bootstrapping process to find precon¬ 
dition candidates outside the current precondition (^Precond) 
for which we might be able to guarantee termination. 

Example. Let us consider again function h in Fig. [T] This 
time, we will assume we have the invariant 0 < x < M (with 
M ’.= 2^^ — 1). We bootstrap by assuming Precond = false 


and searching for values of y satisfying true A false A a:=0 A 
0 < cc < M. One possibility is y = 0. We then compute 
the invariant under the precondition y = 0 and get a: = 0. 
Obviously, we cannot find a termination argument in this case. 
Hence, we start over and search for values of y satisfying 
y 7 ^ 0 A -^false A a:=0 A 0<a:<10. This formula is for instance 
satisfied by y = 1. This time we get the invariant 0<x<10 
and the ranking function —x. Thus, we have to solve 
3e : V[y, e) A 0<x<M A x'=x+y A a:<10 
-'[—x> — x') 

to compute an over-approximating precondition over the 
template V. In this case, V[y,e) turns out to be y = 0, 
therefore its negation y 0 is the Precond that we get. 
Finally, we have to check for further precondition candidates, 
but y 7 ^ 0 A -'(y 7 ^ 0) A a;=0 A 0<x<M is obviously UNSAT. 
Hence, we return the sufficient precondition for termination 

2/ 7^ 0. 

C. Conditional Termination 

We now extend the formalisation to Algorithm [T] which 
additionally requires the computation of under-approximating 
calling contexts and sufficient preconditions for termination 
(procedure compPrecondTerm, see Alg. [3- 

First, compPrecondTerm computes in line [3 an over¬ 
approximating invariant entailed by the candidate pre¬ 

condition. Inv'jp is computed through Def. |3 by conjoining 
the candidate precondition to the antecedent. Then, line |3 
computes the corresponding termination argument RRf by 
applying Lemma [3 using Inv°fp instead of Inv°f. Since the 
termination argument is under-approximating, we are sure that 
/ terminates for this candidate precondition if RRf true. 

Remark 2. The available under-approximate information 
CallCtx'f A Sums'f A PrecondsJ, -where 
Sumsj = Aca//i hj in f 9hj 

Suml.[xP-^^j,xP-°'^*j) 
and Preconds} = h, in f 9h, => Precondl^ 
could be conjoined with the antecedents in Prop. |3 and 
Prop. 13 in order to constrain the search space. However, 
this is neither necessary for soundness nor does it impair 
soundness, because the same information is used in Props. |6| 

[3 

Then, in line[T3of compPrecondTerm, we compute under¬ 
approximating (sufficient) preconditions for traces satisfying 
the termination argument RR via over-approximating the 
traces violating RR. 

Now, we are left to specify the formulae corresponding to 
the following functions: 

• compCallCtx'^ (Def. |7li 

• compNecPrecond (Def. |6]i 

We use the superscript “ to indicate negations of under¬ 
approximating information. 

Definition 6 (Line [T3 of compPrecondTerm). A precondi¬ 
tion for termination Precond'j in backward calling context 
CallCtx'j and with forward invariants Inv°f is Precond'^ = 










-iPrecondj, i.e. the negation of a satisfiability witness 
Precond^ for: 

3Precond]^., Inv'f, Sumj : Va:*", a:, a:', a;", a;°“‘ : 
-'C'anC'tej(a;*", a:°"‘) A Inv°f{x) A Sums°f/\ 

Sums'j A Assumptionsf(x) A Assertionsf{x) =► 
(ylnit{x'^'^^ x") A Inv^ {x") A Out{x, a;°“*) 

=> Inv^(x) A SumJ {x''^, x°^*) A Precond'f {x™)) 
A [{-^TZTZf{x,x') V Preconds'f)A 

Invf{x') A Trans{x,x') Inv^lx)) 


Lemma 6. CallCtx^. is under-approximating. 

Proof sketch. The computation is based on the negation of 
the under-approximating calling context of / and the negated 
under-approximating summaries for the function calls in /. By 
Thm. 12 this leads to an over-approximation of the negation 
of the calling context for hi. □ 

Theorem 2. A procedure f terminates for all values of a;*" 
satisfying Precond'j. 

Proof sketch. By induction over the acyclic call graph using 
Lemmae |5] and |6] □ 


with Sums'} = h, in f 9h, 

^Sum'^ [h] {xP-'''j, xP-^^^j ) 

and Preconds} = \J ^ 

-^Precond" [h] {xP-'^'j , xP-°''‘* j ). 

This formula is similar to Def. 12 but w.r.t. backward calling 
contexts and summaries, and strengthened by the (forward) 
invariants Inv}. We denote the negation of the witnesses found 

for the summary and the invariant by Sum} = ^Sum} and 
Inv} = -ninv}, respectively. 

Lemma 5. Precond}, Sum} and Inv} ore under¬ 
approximating. 

Proof sketch. We compute an over-approximation of the nega¬ 
tion of the precondition w.r.t. the negation of the under¬ 
approximating termination argument and the negation of fur¬ 
ther under-approximating information (backward calling con¬ 
text, preconditions of procedure calls) — by the soundness of 
the synthesis (see Thm. |2 in Sec. |V]i, this over-approximates 
the non-terminating traces, and hence under-approximates the 
terminating ones. Hence, the precondition is a sufficient pre¬ 
condition for termination. The term -nRRf[x, x')\/Preconds} 
characterises non-terminating states in the invariants of /: for 
these, either the termination argument for / is not satisfied or 
the precondition for termination of one of the callees does not 
hold. □ 

Finally, we have to define how we compute the under-appro¬ 
ximating calling contexts: 

Definition 7 {compCallCtx"'). The backward calling context 
CallCtx'}^. for procedure call hi in procedure f in backward 
calling context CallCtx} and forward invariants Inv} is 

CallCtx}. = -'CallCtx'}^., the negation of a satisfiability 
witnesses for: 

BCallCtxl^, Inv} : 'ix''',x, x', xP-'^'i, xP-°'^\, : 

-nCallCtx}{x"'‘,x°'^*^) A Inv}{x) A Sums}A 

Sums} A Assumptionsj(x) A Assertionsf{x) => 

(y Out{x^ x°''‘^) Inv}{x)^ 

A [lnv}{x') A Trans(x,x') 

Inv}{x) A CallCtxl^{xP-''',xP-°'^*)) 


D. Context-Sensitive Summaries 

The key idea of interprocedural analysis is to avoid re¬ 
analysing procedures that are called multiple times. For that 
reason. Algorithm [T] first checks whether it can re-use already 
computed information. For that purpose, summaries are stored 
as implications CallCtx° => Sum°. As the call graph is 
traversed, the possible calling contexts CallCtx}. for a proce¬ 
dure h are collected over the call sites i. NeedToReAnalyze° 
(Line |2 in Alg. [2) checks whether the current calling context 
CallCtx}. is subsumed by calling contexts \/^ CallCtx}. that 
we have already encountered, and if so, Sums[h] is reused; 
otherwise it needs to be recomputed and joined conjunctively 
with previously inferred summaries. The same considerations 
apply to invariants, termination arguments and preconditions. 

V. Template-Based Static Analysis 

In this section, we give a brief overview of our synthesis 
engine, which serves as a backend for our approach (it solves 
the formulae in Definitions |2 |2 HI and Q (see Sec. llVb). 

Our synthesis engine employs template-based static analysis 
to compute ranking functions, invariants, summaries, and call¬ 
ing contexts, i.e., implementations of functions compInvSum° 
and compCallCtx° from the second-order constraints defined 
in Sec. To be able to effectively solve second-order 
problems, we reduce them to first-order by restricting the space 
of solutions to expressions of the form T{x,d) where 

• d are parameters to be instantiated with concrete values 
and x are the program variables. 

• T is a template that gives a blueprint for the shape of 
the formulas to be computed. Choosing a template is 
analogous to choosing an abstract domain in abstract 
interpretation. To allow for a flexible choice, we consider 
template polyhedra 0. 

We state give here a soundness result: 

Theorem 3. Any satisfiability witness d of the reduction of 
the second order constraint for invariants in Def. Q] using 
template T 

3d,yx"'’,x,x' : Init{x"'',x) T(x,d) 

A T{x,d) A Trans{x,x') T{x}d) 

satisfies \/x : Inv(x) => P{x,d), i.e. 'T{x,d) is a sound 
over-approximating invariant. Similar soundness results hold 
true for summaries and calling contexts. 


This ultimately follows from the soundness of abstract 
interpretation Q. Similar approaches have been described, for 
instance, by Qoi, mu, II 2 . However, these methods consider 
programs over mathematical integers. 

Ranking functions require specialised synthesis techniques. 
To achieve both expressiveness and efficiency, we generate 
linear lexicographic functions an, in. Our ranking-function 
synthesis approach is similar to the TAN tool O but extends 
the approach from monolithic to lexicographic ranking func¬ 
tions. Further, unlike TAN, our synthesis engine is much more 
versatile and configurable, e.g., it also produces summaries and 
invariants. 

We refer to Appendix 0 , which includes a detailed 
description of the synthesis engine, our program encoding, 
encoding of bit-precise arithmetic, and tailored second-order 
solving techniques for the different constraints that occur 
in our analysis. In the following section, we discuss the 
implementation. 

VI. Implementation 

We have implemented the algorithm in 2LS ifT^ . a static 
analysis tool for C programs built on the CPROVER frame¬ 
work, using MiniSat 2.2.0 as back-end solver. Other SAT and 
SMT solvers with incremental solving support would also be 
applicable. Our approach enables us to use a single solver 
instance per procedure to solve a series of second-order queries 
as required by Alg. [T] This is essential as our synthesis algo¬ 
rithms make thousands of solver calls. Architectural settings 
(e.g. bitwidths) can be provided on the command line. 
Bitvector Width Extension As aforementioned, the seman¬ 
tics of C allows integers to wrap around when they over/un¬ 
derflow. Let us consider the following example, for which we 
want to find a termination argument using Algorithm |4l 
void f() { for(unsigned char x; ; x++); } 

The ranking function synthesis needs to compute a value 
for template parameter ^ such that £{x—x') > 0 holds for all 
X, x' under transition relation a;'=a;-|-l and computed invariant 
true (for details of the algorithm refer to Appendix O ). 

Thus, assuming that the current value for £ is —1, the con¬ 
straint to be solved (Algorithm |4] Line |3l is true A x'=x+\ A 
-!(—l(a;—a;'))>0), or -i(—l(a:—(a:-|-l))>0), for short. While 
for mathematical integers this is SAT, it is UNSAT for 
signed bit-vectors due to overflows. For a:=127, the over¬ 
flow happens such that a:-|-l=—128. Thus, 127—(—128)>0 
becomes —1>0, which makes the constraint UNSAT, and 
we would incorrectly conclude that —x is a ranking func¬ 
tion, which does not hold for signed bitvector semantics. 
However, if we extend the bitvector width to k=Q such 
that the arithmetic in the template does not overflow, then 
-!(—1 • {{signedg)121—{signedg){—12S)) > 0) evaluates to 
255 > 0, where signed), is a cast to a fc-bit signed integer. 
Now, a;=127 is a witness showing that —x is not a valid 
ranking function. 

For similar reasons, we have to extend the bit-width of fc-bit 
unsigned integers in templates to (fc-l-l)-bit signed integers to 
retain soundness. 


Optimisations Our ranking function synthesis algorithm 
searches for coefficients i such that a constraint is UNSAT. 
However, this may result in enumerating all the values for 
i in the range allowed by its type, which is inefficient. 
In many cases, a ranking function can be found for which 
ij € { — 1,0,1}. In our implementation, we have embedded 
an improved algorithm (Algorithm |4] in Appendix O. into an 
outer refinement loop which iteratively extends the range for 
£ if a ranking function could not be found. We start with 

G { —1,0,1}, then we try £j G [—10,10] before extending 
it to the whole range. 

Further Bounds As explained in Algorithm ID we bound 
the number of lexicographic components (default 3), because 
otherwise Algorithm |4] does not terminate if there is no 
number n such that a lexicographic ranking function with n 
components proves termination. 

Since the domains of x,x' in Algorithm |4] and of at™ in 
Algorithm [3] might be large, we limit also the number of 
iterations (default 20) of the while loops in these algorithms. 
In the spirit of bounded model checking, these bounds only 
restrict completeness, i.e., there might exist ranking functions 
or preconditions which we could have found for larger bounds. 
The bounds can be given on the command line. 

VII. Experiments 

We performed experiments to support the following claims: 

1) Interprocedural termination analysis (IPTA) is faster than 
monolithic termination analysis (MTA). 

2) The precision of IPTA is comparable to MTA. 

3) 2LS outperforms existing termination analysis tools. 

4) 2LS’s analysis is bit-precise. 

5) 2LS computes usable preconditions for termination. 

We used the product line benchmarks of the El benchmark 
repository. In contrast to other categories, this benchmark 
set contains programs with non-trivial procedural structure. 
This benchmark set contains 597 programs with 1100 to 
5700 lines of code (2705 on average)0 33 to 136 procedures 
(67 on average), and 4 to 10 loops (5.5 on average). Of 
these bencharks, 264 terminate universally, whereas 333 never 
terminate. 

The experiments were run on a Xeon X5667 at 3 GHz 
running Fedora 20 with 64-bit binaries. Memory and CPU time 
were restricted to 16 GB and 1800 seconds per benchmark, 
respectively (using mi Using 2LS with interval templates 
was sufficient to obtain reasonable precision. 

Modular termination analysis is fast We compared IPTA 
with MTA (all procedures inlined). Table U shows that IPTA 
times out on 2.3 % of the benchmarks vs. 39.7 % for MTA. 
The geometric mean speed-up of IPTA w.r.t. MTA on the 
benchmarks correctly solved by both approaches is 1.37. 

In order to investigate how the 30m timeout affects MTA, 
we randomly selected 10 benchmarks that timed out for 30 m 
and re-ran them: 1 finished in 32 m, 3 after more than Ih, 6 
did not finish within 2 h. 

“^Measured using cloc 1.53. 



2LS IPTA 

2LS MTA 

TAN 

Ultimate 

terminating 

249 

26 

18 

50 

non-terminating 

320 

333 

3 

324* 

potentially non-term. 

14 

1 

425 

0 

timed out 

14 

237 

150 

43 

en'ors 

0 

0 

1 

180 

total run time (h) 

58.7 

119.6 

92.8 

23.9 


TABLE I 

Tool comparison (• see text). 


Modular termination analysis is precise Again, we com¬ 
pare IPTA with MTA. Table |I] shows that IPTA proves 94 % of 
the terminating benchmarks, whereas only 10% were proven 
by MTA. MTA can prove all never-terminating benchmarks 
including 13 benchmarks where IPTA times out. MTA times 
out on the benchmarks that cause 13 additional potentially 
non-terminating outcomes for IPTA. 

2LS outperforms existing termination analysis tools We 

compared 2LS with two termination tools for C programs from 
the SV-COMP termination competition, namely IT^ and ll20l . 

Unfortunately, the tools 1211 . Il2^ . Il23l . Il24l . and ||251 have 
limitations regarding the subset of C that they can handle that 
make them unable to analyze any of the benchmarks out of 
the box. We describe these limitations in ll26l . Unfortunately, 
we did not succeed to generate the correct input files in 
the intermediate formats required by ll27l and 1^ using the 
recommended frontends ll29l and m- 

TAN ifTSl . and KiTTeL/KoAT IS) support bit-precise C 
semantics. Ultimate uses mathematical integer reasoning but 
tries to ensure conformance with bit-vector semantics. Also, 
Ultimate uses a semantic decomposition of the program lUTl 
to make its analysis efficient. 

Table U shows lists for each of the tools the number of 
instances solved, timed out or aborted because of an internal 
error. We also give the total run time, which shows that 
analysis times are roughly halved by the modular/interpro¬ 
cedural approaches (2LS IPTA, Ultimate) in comparison with 
the monolithic approaches (2LS MTA, TAN). Ultimate spends 
less time on those benchmarks that it can prove terminating, 
however, these are only 19% of the terminating benchmarks 
(vs. 94% for 2LS). If Ultimate could solve those 180 bench¬ 
marks on which it fails due to unsupported features of C, we 
would expect its performance to be comparable to 2LS. 

Ultimate and 2LS have different capabilities regarding non¬ 
termination. 2LS can show that a program never terminates for 
all inputs, whereas Ultimate can show that there exists a poten¬ 
tially non-terminating execution. To make the comparison fair, 
we counted benchmarks flagged as potentially non-terminating 
by Ultimate, but which are actually never-terminating, in the 
non-terminating category in Table |T] (marked *). 

2LS’s analysis is bit-precise We compared 2LS with 
Loopus on a collection of 15 benchmarks (ABC_ex01.c 
to ABC_exl5.c) taken from the Loopus benchmark suite 


void exl5(int m, int n, int p, int q) { 

for (int i = n; i >= 1; i = i — 1) 

for (int i = 1; i <= m; 1 = 1 + 1) 

for (int k = i ; k <= p; k = k + 1) 

for (int 1 =q; 1 <= j ; 1 = 1 + 1) 

} 

Fig. 3. Example ABC_exl5 . c from the Loopus benchmarks. 

void createBack (struct SDL_Surface *back_surf) 

{ 

struct SDL_Rect pos ; 

struct SDL_Surface *img = images [img_back]—>image ; 

for(int x=0; ! ( s >=(♦ back_surf)—>h ); s+=img—>h) { 

for(int y = 0; ! (y >=(* back_surf)—>w); y+=img—>w) { 

pos.x = (signed short int)x; 
pos.y = (signed short int)y; 

SDL_UpperBlit (img , NULL, *back_surf , &pos); 

} } } ' 

Fig. 4. Example createBack from Debian package abe. 

II 22 I . While they are short (between 7 and 41 LOC), the main 
characteristic of these programs is the fact that they exhibit 
different terminating behaviours for mathematical integers 
and bit-vectors. For illustration, ABC_ex08 . c shown Fig. [3 
terminates with mathematical integers, but not with machine 
integers if, for instance, m equals INT MAX. Next, we sum¬ 
marise the results of our experiments on these benchmarks 
when considering machine integers: 

• only 2 of the programs terminate (ABC_ex0 8.c and 
ABC_exl 1. c), and are correctly identified by both 2LS 
and Loopus. 

• for the rest of 13 non-terminating programs, Loopus 
claims they terminate, whereas 2LS correctly classifies 9 
as potentially non-terminating (including ABC_ex0 8 .c 
in Fig. O and times out for 4. 

2LS computes usable precouditious for termiuatiou This 
experiment was performed on benchmarks extracted from 
Debian packages and the linear algebra library CLapack. 

The quality of preconditions, i.e. usability or ability to help 
the developer to spot problems in the code, is difficult to 
quantify. We give several examples where function terminate 
conditionally. The abe package of Debian contains a function, 
shown in Fig. @1 where increments of the iteration in a loop 
are not constant but dynamically depend on the dimensions 
of an image data structure. Here 2LS infers the precondition 
img h > 0 /\ img w > 0. 

The example in Fig. |5] is taken from the benchmark 
basename in the busybox-category of SVCOMP 2015, 
which contains simplified versions of Debian packages. The 
termination of function full_write depends on the return 
value of its callee function safe_write. Here 2LS infers 
the calling context cc > 0, i.e. the contract for the function 
safe_write, such that the termination of full_write is 
guaranteed. Given a proof that saf e_write terminates and 
returns a strictly positive value regardless of the arguments it 
is called with, we can conclude that full_write terminates 
universally. 
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signed long int full_write ( signed int fd , 
const void *buf, unsigned long int len , 
unsigned long int cc) { 

signed long int total = (signed long int)0; 

for ( ; ! ( len == Oul ); 

len = len — (unsigned long int)cc) { 
cc = safe_write (fd , buf , len); 
if(cc < 01) { 

if (!( total == 01 )) 
return total; 
return cc ; 

} 

total = total + cc; 

buf = (const void *)((const char *)buf + cc); 

} } 

Fig. 5. Example from SVCOMP 2015 busybox. 

int f(int *sx, int n, int incx) { 

int nincx = n * incx; 

int stemp=0; 

for (int i=0; incx<0 ? i >= nincx: i<= nincx; 
i+=incx) { 
stemp += sx [ i — 1 ]; 

} 

return stemp ; 

} 

Fig. 6. Non-unit increment from CLapack. 

The program in Fig. |6] is a code snippet taken from the 
summation procedure sasum within 13^ . the C version of the 
popular LAPACK linear algebra library. The loop in procedure 
f does not terminate if incx = 0. If incx > 0 (incx < 0) the 
termination argument is that i increases (decreases). Therefore, 
incx 7^ 0 is a termination precondition for f . 

VIII. Limitations, Related Works and Future 
Directions 

Our approach makes significant progress towards analysing 
real-world software, advancing the state-of-the-art of termina¬ 
tion analysis of large programs. Conceptually, we decompose 
the analysis into a sequence of well-defined second-order pred¬ 
icate logic formulae with existentially quantified predicates. In 
addition to ll^ . we consider context-sensitive analysis, under¬ 
approximate backwards analysis, and make the interaction 
with termination analysis explicit. Notably, these seemingly 
tedious formulae are actually solved by our generic template- 
based synthesis algorithm, making it an efficient alternative to 
predicate abstraction. 

An important aspect of our analysis is that it is bit-precise. 
As opposed to the synthesis of termination arguments for lin¬ 
ear programs over integers (rationals) ll34l . 135], 12, l3^ . llJTl . 
O, 02, this subclass of termination analyses is substantially 
less covered. While 03, GSl present methods based on a 
reduction to Presburger arithmetic, and a template-matching 
approach for predefined classes of ranking functions based 
on reduction to SAT- and QBF-solving, f39l only compute 
intraprocedural termination arguments. 

There are still a number of limitations to be addressed, all 
of which connect to open challenges subject to active research. 
While some are orthogonal (e.g., data structures, strings, 
refinement) to our interprocedural analysis framework, others 


(recursion, necessary preconditions) require extensions of it. In 
this section, we discuss related work, as well as, characteristics 
and limitations of our analysis, and future directions (cost 
analysis and concurrency). 

Dynamically allocated data structures We currently ig¬ 
nore heap-allocated data. This limitation could be lifted by 
using specific abstract domains. For illustration, let us consider 
the following example traversing a singly-linked list. 

List x; while (x != NULL) { x = x—>next ; } 

Deciding the termination of such a program requires knowl¬ 
edge about the shape of the data structure pointed by x, 
namely, the program only terminates if the list is acyclic. Thus, 
we would require an abstract domain capable of capturing 
such a property and also relate the shape of the data structure 
to its length. Similar to 03, we could use M in order 
to abstract heap-manipulating programs to arithmetic ones. 
Another option is using an abstract interpretation based on 
separation logic formulae which tracks the depths of pieces of 
heaps similarly to ED. 

Strings and arrays Similar to dynamically allocated data 
structures, handling strings and arrays requires specific ab¬ 
stract domains. String abstractions that reduce null-terminated 
strings to integers (indices, length, and size) are usually suffi¬ 
cient in many practical cases; scenarios where termination is 
dependent on the content of arrays are much harder and would 
require quantified invariants ES- Note that it is favorable to 
run a safety checker before the termination checker. The latter 
can assume that assertions for buffer overflow checks hold 
which strengthens invariants and makes termination proofs 
easier. 

Recursion We currently use downward fixed point iterations 
for computing calling contexts and invariants that involve 
summaries (see Remark [D- This is cheap but gives only 
imprecise results in the presence of recursion, which would 
impair the termination analysis. We could handle recursions by 
detecting cycles in the call graph and switching to an upward 
iteration scheme in such situations. Moreover, an adaptation 
regarding the generation of the ranking function templates is 
necessary. An alternative approach would be to make use of 
the theoretic framework presented in B3l for verifying total 
correctness and liveness properties of while programs with 
recursion. 

Template refinement We currently use interval templates 
together with heuristics for selecting the variables that should 
be taken into consideration. This is often sufficient in practice, 
but it does not exploit the full power of the machinery in place. 
While counterexample-guided abstraction refinement (CE- 
GAR) techniques are prevalent in predicate abstraction El, 
attempts to use them in abstract interpretation are rare ES- 
We consider our template-based abstract interpretation that 
automatically synthesises abstract transformers more amenable 
to refinement techniques than classical abstract interpretations 
where abstract transformers are implemented manually. 

Sufficient preconditions to termination Currently, we 


compute sMj^c/enf preconditions, i.e. under-approximating pre¬ 
conditions to termination via computing over-approximating 
preconditions to potential non-termination. The same concept 
is used by other works on conditional termination 121, ll46l . 
However, they consider only a single procedure and do not 
leverage their results to perform interprocedural analysis on 
large benchmarks which adds, in particular, the additional 
challenge of propagating under-approximating information up 
to the entry procedure (e.g. Bril '). Moreover, by contrast to 
Cook et al 121 who use an heuristic FiNiTE-operator left 
unspecified for bootstrapping their preconditions, our boot¬ 
strapping is systematic through constraint solving. 

We could compute necessary preconditions by computing 
over-approximating preconditions to potential termination (and 
negating the result). However, this requires a method for 
proving that there exist non-terminating executions, which 
is a well-explored topic. While l48l dynamically enumerate 
lasso-shaped candidate paths for counterexamples, and then 
statically prove their feasibility, l49l prove nontermination via 
reduction to safety proving. In order to prove both termination 
and non-termination, EQI compose several program analyses 
(termination provers for multi-path loops, non-termination 
provers for cycles, and safety provers). 

Cost analysis A potential future application for our work is 
cost and resource analysis. Instances of this type of analyses 
are the worst case execution time (WCET) analysis lISTI . as 
well as bound and amortised complexity analysis ED, m, 
ll54l . The control flow refinement approach ll55l . If56l instru¬ 
ments a program with counters and uses progress invariants 
to compute worst case or average case bounds. 

Concurrency Our current analysis handles single-threaded 
C programs. One way of extending the analysis to multi¬ 
threaded programs is using the rely-guarantee technique which 
is proposed in ll57ll . and explored in several works ll58]l . Il59l . 
ll60l for termination analysis. In our setting, the predicates 
for environment assumptions can be used in a similar way as 
invariants and summaries are used in the analysis of sequential 
programs. 

IX. Conclusions 

While many termination provers mainly target small, hard 
programs, the termination analysis of larger code bases has 
received little attention. We present an algorithm for interpro¬ 
cedural termination analysis for non-recursive programs. To 
our knowledge, this is the first paper that describes in full detail 
the entire machinery necessary to perform such an analysis. 
Our approach relies on a bit-precise static analysis combining 
SMT solving, template polyhedra and lexicographic, linear 
ranking function templates. We provide an implementation of 
the approach in the static analysis tool 2LS, and demonstrate 
the applicability of the approach to programs with thousands 
of lines of code. 
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Appendix 

A. Program Encoding 

We encode programs in a representation akin to single-static 
assignment (SSA). We provide a brief review, focusing on the 
modelling of loops and procedure calls. We continue to use 
the program in Fig. [T] as example. 

In SSA, each assignment to a variable gives rise to a 
fresh symbol. For instance, the initialisation of variable x 
corresponds to symbol xq, and the incrementation by y gives 
rise to symbol X 2 - For the return values, additional variables 
such as ry are introduced. In addition, at control-flow join 
points, the values coming from different branches get merged 
into a single (^-variable. For instance, xf is either the initial 
value xq or the value of x after executing the loop, which is 
denoted as xf. In the case of branches, the choice is controlled 
using the condition of the branch. 

In the case of loops, the choice between the value at the 
loop entry point and the value after the execution of the loop 
body is made using a non-deterministic Boolean symbol I S 3 . 
That ensures the SSA remains acyclic and loops are over¬ 
approximated. Moreover, it allows us to further constrain 
with loop invariants inferred by our analyses. 

In addition to data-flow variables, there are guard variables 
gi, which capture the branch conditions from conditionals 
and loops. For instance, the loop condition is g 2 , and the 
conditional around the invocation of / is 513 . 

To facilitate interprocedural analysis, our SSA contains a 
placeholder for procedure calls, which ensures that procedure 
calls are initially havocked. It can be constrained using the 
summaries computed in the course of the analysis (cf. Sec. H. 

Regarding pointers, a may-alias analysis is performed dur¬ 
ing translation to SSA form and case splits are introduced 
accordingly. 

B. Computing Over-Approximating Abstractions 

To implement Algorithm [T] we need to compute invari¬ 
ants, summaries, and calling contexts, i.e., implementations of 
functions compInvSum° and compCallCtx°. As described in 
Sec. mi invariants and calling contexts can be declaratively 
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Fig. 7. SSA form for example in Fig. [T] 

expressed in second-order logic. To be able to effectively 
solve such second-order problems, we reduce them to first- 
order by restricting the space of solutions to expressions of 
the form T{x,d) where d are parameters to be instantiated 
with concrete values and x are the program variables. 
Template Domain. An abstract value 6 represents the set 
of all X that satisfy the formula T{x,5) (concretisation). 
We write _L for the abstract value denoting the empty set 
T(a:,-L) = false, and T for the abstract value denoting the 
whole domain of x: Tix, T) = true. 

Choosing a template is analogous to choosing an abstract 
domain in abstract interpretation. To allow for a flexible 
choice, we consider template polyhedra m--T= {Ax < d) 
where A is a matrix with fixed coefficients. Polynomial tem¬ 
plates subsume intervals, zones and octagons ED- Intervals, 
for example, give rise to two constraints per variable xp. 
Xi < dii and —Xi < da- We call the constraint generated 
by the r* row of matrix A the row of the template. 

To encode the context of template constraints, e.g., inside 
a loop or a conditional branch, we use guarded templates. In 
a guarded template each row r is of the form Gr TV 
for the r* row Tr of the base template domain (e.g. template 
polyhedra). The guards are uniquely defined by the guards 
of the SSA variables appearing in Tr. Gr denotes the guard 
associated to the variables x at the loop head, and GJ, the 
guard associated to the variables x' at the end of the loop 
body. A guarded template in terms of the variables at the loop 
head is of the form; T = Ar => TV (respectively T' — 
Ar '^r if expressed in terms of the variables at the 

end of the loop body). 

Inferring abstractions. Fixing a template reduces the 
second-order search for an invariant to the first-order search 
for template parameters: 

3d : Va:*", a:, a:': Init{x'‘^,x) T{x,d) 

A T{x,d) A Trans{x,x') =^T'{x',d) . 

By substituting the symbolic parameter d by a concrete value 
5, we see that T{x,6) is an invariant if and only if the 
following formula is unsatisflable: 

3a;*”, a;, a;': Init{x'^'^,x) A ^T{x,S) 

V T{x,S) A Trans{x,x') A-<T'{x',d) . 

As these vectors represent upper bounds on expressions, 
the most precise solution is the smallest vector in terms of 


point-wise ordering. We solve this optimisation problem by 
iteratively calling an SMT solver. Similar approaches have 
been described, for instance, by Qol, im, 02. However, 
these methods consider programs over mathematical integers. 

Computing overapproximations for calling contexts is sim¬ 
ilar to computing invariants or summaries. They only differ in 
the program variables appearing in the templates: 
for calling contexts, x,x' for invariants, and for 

summaries. 

C. Termination Analysis For One Procedure 

In this section we give details on the algorithm that we use 
to solve the formula in Lemma [3] (see Sec. II V- Al l. 

Monolithic ranking functions are complete, i.e., termination 
can always be proven monolithically if a program terminates. 
However, in practice, combinations of linear ranking functions, 
e.g., linear lexicographic functions ifOl . ifMll are preferred, as 
monolithic linear ranking functions are not expressive enough, 
and non-linear theories are challenging for existing SMT 
solvers, which handle the linear case much more efficiently. 

1) Lexicographic Ranking Functions: 

Definition 8 (Lexicographic ranking function). A lexi¬ 
cographic ranking function R for a transition relation 
Trans{x,x') is an n-tuple of expressions {Rn, Rn-i,..., Ri) 
such that 

3A > 0 : \/x, x' : Trans{x, x') A 3i e [1, n] : 

Ri{x) > 0 (Bounded) 

A Ri{x) — Ri{x') > A (Decreasing) 

A 'ij > i ■. Rj{x) — Rj{x') > 0 (Unaffecting) 

Notice that this is a special case of Definition |2] In par¬ 
ticular, the existence of A > 0 and the Bounded condition 
guarantee that > is a well-founded relation. 

Before we encode the requirements for lexicographic rank¬ 
ing function into constraints, we need to adapt it in accordance 
with the bit-vector semantics. Since bit-vectors are bounded, 
it follows that the Bounded condition is trivially satisfied 
and therefore can be omitted. Moreover, bit-vectors are dis¬ 
crete, hence we can replace the Decreasing condition with 
Ri{x) — Ri{x') > 0. The following formula, LR, holds if and 
only if {Rn, Rn-i, ■■■, Ri) is a lexicographic ranking function 
with n components over bit-vectors. 

LR^{x,x') =\J^^i{Ri{x) — Ri{x') > 0 A 

A"=i+i(-RA®) - > 0)) 

Assume we are given the transition relation Trans{x,x') of 
a procedure /. The procedure / may be composed of several 
loops, and each of the loops is associated with a guard g 
that expresses the reachability of the loop head (see Sec. 0 . 
That is, suppose / has k loops, then the lexicographic ranking 
function to prove termination of / takes the form: 

RR^{x,x') = ALi5*(®) LR'f\x,x') 







2) Synthesising Lexicographic Ranking Functions: Rank¬ 
ing techniques for mathematical integers use e.g. Farkas’ 
Lemma, which is not applicable to bitvector operations. We 
use a synthesis approach (like the TAN tool ifTSlI l and extend 
it from monolithic to lexicographic ranking functions. 

We consider the class of lexicographic ranking functions 
generated by the template where Ri{x) is the product iiX 
with the row vector ii of template parameters. We denote the 
resulting constraints for loop i as {x,x 'where 

is the vector , £^'). The constraints for the ranking 

functions of a whole procedure TZTZix, x', L”), where L” is 
the vector ..., 

Putting all this together, we obtain the following reduction 
of ranking function synthesis to a first-order quantifier elimi¬ 
nation problem over templates: 

3L'* : Vx, x' : Inv{x) A Trans{x, x') TZTZ{x, x', L^) 

To complete the lattice of ranking constraints CTZ^'), we 
add the special value T to the domain of We define 
£72."’(x, x', T) = true indicating that no ranking function 
has been found for the given template (“don’t know”). We 
write _L for the equivalence class of bottom elements for 
which £72"’(x, x', £"’) evaluates to false, meaning that the 
ranking function has not yet been computed. For example, 0 
is a bottom element. Note that this intuitively corresponds to 
the meaning of L and T as known from invariant inference 
by abstract interpretation (see Sec. 0. 


Algorithm 4: compTermArg 


Input: procedure / with invariant Inv, bound on number of 
lexicographic components N 
Output: ranking constraint 7272 

1 n ^ l''; A" ^ A*’; M ^ 0^ 

2 let (/3 = Invix) A Trans{x, x'); 

3 while true do 

4 let 'tp = (p A x', A'^); 

5 solve -ip for x^x' \ 

6 if UNSAT then return 1ZTl(x,x\ let (X;X0 ^ 

model of 'tp\ 


7 

8 
9 

10 

11 

12 


let i£{i\ -^(gi ^ £72"’(x, x', AD)}; 

solve 6 for £"’; 
if UNSAT then 

if rii < A then riit—ni-fl; A"‘ =±; Mi = % else 
return 7272(x, x', T*’) 


13 

14 

15 


else 


let m be a model of 6; 
■ m; 


int x=l, y=l; 
while(x>0) { 

if(y<10) x=nondet(); 
else X-; 
if(y<100) y++; 


Trans{{x,y), {x',y')) = 
a;>0 =^( ( 3/>10 => x'=x—l) 

A (y<100^y'=y+l) 

A {y>100 ^ y'= y) )A 
x<0 =^( x' = X A y' = y ) 


Fig. 8. Example for Alg. |4](with simplified Trans). 


In each iteration, our algorithm checks the validity of the 
current ranking function candidate. If it is not yet a valid 
ranking function, the SMT solver returns a counterexample 
transition. Then, a new ranking function candidate that sat¬ 
isfies all previously observed counterexample transitions is 
computed. This process is bound to terminate because the 
finiteness of the state space. 

We start from the bottom element (Line [T]) for ranking 
functions with a single component (Line [T]) and solve the 
corresponding formula -ip, which is true A Trans{{x, y), {x', 
y')) A -^false (Line |5]l. ip is satisfiable with the model 
(1,100,0,100) for {x,y,x',y'), for instance. This model 
entails the constraint (\l\ A- lOOiy) — {Ot], -b lOOiy) > 0, 
i.e. £]. > 0, in Line|9] from which we compute values for the 
template coefficients and £y. This formula is given to the 
solver (Line [Toll which reports SAT with the model (1,0) for 
{£x,£y), for example. We use this model to update the vector 
of template parameter values A} to (1,0) (Line flSTl. which 
corresponds to the ranking function x. 

We then continue with the next loop iteration, and check the 
current ranking function (Line|5]l. The formula true A Trans A 
-'(x — x' > 0) is satisfiable by the model (1,1,1001, 2) for 
{x,y,x',y'), for instance. This model entails the constraint 
(4 + (-1) - (10014 + 24 ) > 0 , i.e. 10004 - 24 > 0) in 
Line |9] which is conjoined with the constraint > 0 from 
the previous iteration. The solver (Line [Tol l will tell us that 
this is UNSAT. 

Since we could not find a ranking function we add another 
component to the lexicographic ranking function template 
(Line fT2l i. and try to solve again (Line |2i and obtain the 
model (1,99,0,100) for (x,y,x',y'), for instance. Then in 
Line [Tol the solver might report that the model (0, —1,1,0) 
for (4) 44^)4) satisfies the constraints. We use this model 
to update the ranking function to {—y,x). 

Finally, we check whether there is another witness for 
(— 2 /,x) not being a ranking function (Line |5]l, but this time 
the solver reports the formula to be UNSAT and the algorithm 
terminates, returning the ranking function {—y,x). 


We now use the example in Fig. [S] to walk through Algo¬ 
rithm |4] that we use to solve Lemma [3] (see Sec. IIV-AI) . The 
left-hand side of Fig. [8] is the C code and the right side is its 
transition relation. Since the procedure only has a single loop, 
we will omit the guard {g = true). Also, we assume that we 
have obtained the invariant Inv{x,y) = true. We use Latin 
letters such as x to denote variables and Greek letters such as 
X to denote the values of these variables. 










